QRZ! Ham Radio 6/QRZ Ham Radio Callsign Database - Volume 6.iso/pc/files/t_gtepms/gteintro.txt

Text File | 1994-11-27 | 11.3 KB | 210 lines

Are you presently using an MS-DOS 80286 or 80386 computer as a
platform for your BBS program?  Wouldn't it be nice if you could
unleash all the power in your system's CPU and improve thruput and
gain ports without having to run multiple copies of your BBS program?

Imagine a BBS package written expressly for 80286/80386 CPUs with
net/rom emulation, a multi-connect, multi-tasking AX.25 bulletin board
program with a landline port, remote sysop ID security via an
encrypted password, file server support, tcp/ip as an option, and the
ability to query other similar systems for users when a message is
left for someone not known to that particular BBS!  All this with no
need to run multiple copies of the program and making maximum use of
your system's expanded memory or EEMS/LIM 4.0 capability.

Impossible, you say?  Nope!  Read on.

The package is called the GTE Packet Message Switch (GTEPMS) and was
written by Doug Miller, N2GTE.

GTEPMS was beta-tested in the Greater Baltimore (MD) metropolitan
area; a very congested location for packet operations with literally
dozens of BBSs and a fairly organized nodes network.  The beta testers
ranged from computer programmers to computer dummies (me) and out of
that testing, the first general release version 1.2 was distilled.

The GTEPMS is designed to operate under Quarterdeck's DESQview and
QEMM memory management programs or under DESQview-386, which combines
the two.  It is DESQview-specific and requires the DESQview/QEMM or
DesqView-386 programs in order to operate properly.  Any IBM 80286
clone with at least 2 megabytes of EEMS or LIM 4.0 RAM, or an 80386
with at least two megabytes of memory can run this package.  Most of
the beta testers have been using 386SX computers with expanded memory
from 2 thru 5 megabytes.  A majority are using 4 megabytes, which is
recommended by N2GTE.

The package consists of the GTEPMS program itself,  G8BPQ networking
software, and tcp/ip programs with modifications made by N2GTE.  The
Quarterdeck programs are not part of the package since they are
commercial programs.  You will need to obtain them from a commercial
source, but the PIF-DVP routines which run the BBS under DesqView are
included in the GTEPMS package.  Also included are sample files which
must be made up in order to run the package.

Caution:This is NOT a BBS package for computer novices or beginning
packeteers.  The package assumes a basic knowledge of how DESQview
works, how QEMM works, and how to set up and navigate between Desqview
windows, and a good knowledge of MS-DOS file structure.

HOW IT WORKS:
GTEPMS talks to the outside world via the G8BPQ networking program
written by John Wiseman, G8BPQ.  The two versions of the BPQ code
which are compatible with GTEPMS are versions 3.57 and 3.59.  Later
versions are not, at this time, able to work with GTEPMS, since G8BPQ
radically changed his interface software in versions from 4.0 and
upwards.  The sysop must set up the BPQ program into a net/rom
compatible node which will control all of the ports and connects to
the GTEPMS BBS, and will also interface with any file servers running.
The number of ports and connects are limited only by the number of
TNCs hooked to the BPQ software. BPQ can handle a number of different
TNCs, but they must be TNC-2 type modems and be able to run KISS mode.
An exception is the DRSI PC Packet Adapters which are internal TNCs
and don't need KISS mode to run. Since BPQ can handle up to four DRSI
cards, if you have four empty slots in your computer, you can run up
to eight radio ports without touching the computer's serial ports! For
that matter, if you installed four of the DRSI cards which have two
serial ports instead of radio outputs, you could, theoretically,
connect a dual-port TNC such as the Kantronics KAM or KPC-4 to each
serial port and wind up with 16 radio ports!  That's also the limit
that BPQ can handle.  Wow, a monster BBS system!

All BBS routines work within DESQview windows.  Unlike other BBS
programs, only a few are continually open and others operate only when
needed.  As a routine is called, DESQview opens a window for that
purpose, the program is executed, and the window is closed.  This
helps to keep the BBS from slowing down.  Many routines don't run
unless they're needed, so memory is conserved, and time slices are smaller.

The exception to this is the BPQ code.  BPQ does not operate under
DESQview; instead, it starts up under a batch file when the system is
first booted up and stays resident.

GTEPMS contains three modules which operate the system and are open at
all times in their DesqView windows: LISTER, PORTER, and RESOLVER.

LISTER makes lists of things. It oversee's the databases connected to
the BBS such as the user files, mail files, and so on.  It opens the
RESOLVER and PORTER windows when the system is booted-up and cleans up
the mail files.  It also manages the temporary spool files which are
created during mail in/out routines.

RESOLVER handles all the mail and bulletin actions in the system.
RESOLVER's main job is to get rid of mail and bulletins. It works with
LISTER to match up hierarchical routing and then queue's outstanding
mail and bulletins for forwarding-out or placing local messages for
users to pick up.  RESOLVER also reads the message headers on
bulletins and mail and automatically places new headers in a file
which is read by LISTER to append hierarchical routing to outbound
mail.

PORTER opens and closes the ports used in forwarding and user tasks
and allocates ports to each routine as it is called, and closes those
ports when the task is completed.  Timed routines such as forwarding,
server instructions, also are under PORTER's supervision.

A fourth full-time window is the optional IP module.  This is the
tcp/ip window which controls all tcp/ip functions.  This window is not
required to run the BBS.  It can be left out of the system altogether,
but all of the beta testers have run it, and there are some benefits
to having it running.

Other windows in the system which are opened only when needed are
those dealing with forwarding actions, user actions, connects, sysop
console usage and such.  The sysop may, if he wants, run a full-time
terminal program which interfaces with the BPQ node.  This enables
monitoring of the traffic running on the channel.  It also enables the
sysop to connect to other stations directly.  The sysop gets into his
BBS via a console window in which he can read mail, send mail, do
sysop things like killing mail, and so on.

Whatever tasks are going on, be it multiple user connects, forwarding,
file transfers, or the sysop playing with the console window or
terminal program, the BBS stays up for new connects.

GET THIS:
A very unique feature of the GTEPMS is its ability to query other
GTEPMS systems to check for a "home BBS" for a user unknown to the
system when mail arrives or is placed on the board to that person.
This is called a "Remote Service Request".  Basically, the BBS sends
out a message to the other GTEPMS systems saying: "hey, I have a
message here for so-and-so, any of you guys have any information on
him?"  If any other GTEPMS system has that information, it is relayed
to the querying BBS.  This is all done automatically with no sysop
intervention needed!  This goes a long way towards preventing "stuck"
messages, since, if another GTEPMS system has the "home BBS" info it
will be sent and the querying BBS adjusts the forwarding information
automagically and saves the user information permanently.

WHO ARE YOU? WHERE ARE YOU?
One of the problems sysops must deal with nowadays with the many BBS
programs which ask a user to enter a "home BBS" the first time he/she
connects is the tendency by many people to enter their TNC mailbox
call instead of a full-service BBS call.  Well, this cannot happen
with a GTEPMS system.  The system has a file containing known
full-service BBSs, the same file used by LISTER and added to by
RESOLVER in maintaining the H-routing database.  If a user enters his
mailbox call, the system will not allow him to do so.  He will be told
that the  callsign is not a recognized BBS and to reenter another
"home BBS" call.  If the user persists, he is asked to send a message
to the sysop to negotiate a listing, in case he really IS a
full-service BBS.

SPEED
Many BBS sysops run multiple copies of their BBS program in order to
kludge up a sort of dual-connect system.  The problem is that the
whole thing slows down if all copies of the program are being
accessed.

It's not likely that a GTEPMS system will slow down.  There is no need
to run multiple copies of the code.  This system is FAST! A major
reason for the speed is, of course, the computer's clock speed of
16-25 Mhz as compared to 8-12 Mhz for a PC/XT.  Another reason for the
speed is that  much of the data needed in forwarding is held in a
RAM-disk in the computer's memory.  The information is also held on
disk, but read/write actions go through the RAM disk instead of
through the hard drive.  The recommended size is 128 kilobytes.

To gain even greater speed, some sysops have been using disk caching
to store the last X number of read/written files.  This speeds up the
user's lists and reads, since most of the action on the BBS is in
listing and reading mail.  I carry a 128 kilobyte disk cache on my
system created by software from an unrelated program.  Since I have
five megabytes,the cache does not dent the RAM at all.

SYSOP PASSWORD SECURITY
A potential problem in any BBS is people pirating the sysop's callsign
and giving themselves sysop privileges, then wreaking havoc on the
system by killing messages and creating false ones with the sysop's
call.  This is prevented in the GTEPMS system by the addition of a
password file.  When the sysop connects to the system over a radio or
phone link, or if someone is pirating the call, the password file will
send a series of random numbers which correspond to characters in the
password.  The reply must exactly match the characters in the password
(and is case-sensitive) or the connect will be aborted.  Console
actions are not affected by this, just those connects coming in via
external links.

USER FRIENDLY
GTEPMS is very user friendly (except for that "home BBS" hassle) and
users can pretty much use the BBS intuitively.  The same basic
commands common to most BBSs are used by GTEPMS.  One command which is
unique to GTEPMS is an "over to node" command (O).  Since connects to
the BBS actually go through the BPQ node, a user may elect to connect
to the node after he's finished with his BBS stuff and then use the
node to connect to another station without needing to disconnect from
]the system first.

TCP/IP
Although tcp/ip is not needed to run GTEPMS, it is included in the
distribution disk with many modifications to the KA9Q NET protocol.
Among them is an AX.25 <-> tcp/ip gateway called "MailGaTE" written by
N2GTE which converts SMTP mail to AX.25 and vice versa.  All the
beta testers are running tcp/ip concurrently with GTEPMS.  The two
protocols are unaware of each other but interface with MailGaTe to
port between each other.

So, if you are running a BBS with an 80286 or 80386 machine, you may
want to look into GTEPMS. (freeware? shareware? what mailing addres
and what landline bbs's)